<TITLE>The SSL Protocol</TITLE>

<CENTER>

<A HREF="/index.html">
<IMG SRC="images/standards_ban.gif" WIDTH=468 HEIGHT=32 BORDER=0></A>

<H2>
<FONT SIZE=+3>T</FONT>HE
<FONT SIZE=+3>SSL P</FONT>ROTOCOL
</H2>
</CENTER>


<P>

If you have questions about this specification or would like to send us
your comments please send email to <a href=mailto:ssl-talk@netscape.com>ssl-talk@netscape.com</a>. 
You can subscribe to this mailing list by sending email to 
<a href=mailto:ssl-talk-request@netscape.com>ssl-talk-request@netscape.com</a> and putting the word "<b>subscribe</b>" into the 
subject line or the body of the message. 
<P>
The SSL protocol has been submitted to the IETF as an <a
href="gopher://ds.internic.net:70/00/internet-drafts/draft-hickman-netscape-
ssl-00.txt"><B>Internet
Draft</B></a>. Netscape is actively pursuing the standardization of SSL within
the framework of the IETF standards process and is also working with industry
consortium groups to ensure that open and interoperable security standards
exist now and in the future. If you would like to send us questions, comments
or support during this process please send mail to <A
HREF="mailto:standards@netscape.com">standards@netscape.com</A>.
<P>

Netscape has developed an <A HREF="/newsref/std/sslref.html">SSL reference implementation</A> called
SSLRef. Written in ANSI C and free for noncommercial use, SSLRef
is now available please see here for full details.
<P>

<HR SIZE=4>

<P>
<B>
T<FONT SIZE=-1>HIS</FONT> P<FONT SIZE=-1>ROTOCOL</FONT>
S<FONT SIZE=-1>PECIFICATION</FONT> W<FONT SIZE=-1>AS</FONT>
R<FONT SIZE=-1>EVISED</FONT> O<FONT SIZE=-1>N</FONT>
N<FONT SIZE=-1>OVEMBER</FONT> 29<FONT SIZE=-1>TH,</FONT> 1994:
</B>
<P>

<UL>

<LI>a fundamental correction to the client-certificate authentication
protocol,

<LI>the removal of the username/password messages,

<LI>corrections in some of the cryptographic terminology,

<LI>the addition of a MAC to the messages [see section 1.2],

<LI>the allowance for different kinds of message digest algorithms.

</UL>
<B>
T<FONT SIZE=-1>HIS</FONT> D<FONT SIZE=-1>OCUMENT</FONT> 
W<FONT SIZE=-1>AS</FONT> R<FONT SIZE=-1>EVISED</FONT>
O<FONT SIZE=-1>N</FONT> D<FONT SIZE=-1>ECEMBER</FONT>
22<FONT SIZE=-1>ND,</FONT> 1994:
</B>
<P>


<UL>

<LI>The spec now defines the order the clear key data and secret key
data are combined to produce the master key.

<LI>The spec now explicitly states the size of the MAC instead of making
the reader figure it out.

<LI>The spec is more clear on the actual values used to produce the
session read and write keys.

<LI>The spec is more clear on how many bits of the session key are used
after they are produced from the hash function.

</UL>

<B>
T<FONT SIZE=-1>HIS</FONT> D<FONT SIZE=-1>OCUMENT</FONT>
W<FONT SIZE=-1>AS</FONT> R<FONT SIZE=-1>EVISED</FONT>
O<FONT SIZE=-1>N</FONT> J<FONT SIZE=-1>ANUARY</FONT>
17<FONT SIZE=-1>TH,</FONT> 1995:
</B>
<P>

<UL>

<LI>Defined the category to be informational.

<LI>Clarified ordering of data elements in various places.

<LI>Defined DES-CBC cipher kind and key construction.

<LI>Defined DES-EDE3-CBC cipher kind and key construction.

</UL>

<B>
T<FONT SIZE=-1>HIS</FONT> D<FONT SIZE=-1>OCUMENT</FONT>
W<FONT SIZE=-1>AS</FONT> R<FONT SIZE=-1>EVISED</FONT>
O<FONT SIZE=-1>N</FONT> J<FONT SIZE=-1>ANUARY</FONT>
24<FONT SIZE=-1>TH,</FONT> 1995:
</B>
<P>

<UL>

<LI>Fixed bug in definition of <TT>CIPHER-CHOICE</TT> in
<TT>CLIENT-MASTER-KEY</TT> message. The previous spec erroneously
indicated that the <TT>CIPHER-CHOICE</TT> was an index into the
servers <TT>CIPHER-SPECS-DATA</TT> array, when it was actually
supposed to be the <TT>CIPHER-KIND</TT> value chosen by the client.

<LI>Clarified the values of the <TT>KEY-ARG-DATA</TT>.

</UL>
<B>
T<FONT SIZE=-1>HIS</FONT> D<FONT SIZE=-1>OCUMENT</FONT>
W<FONT SIZE=-1>AS</FONT> R<FONT SIZE=-1>EVISED</FONT>
O<FONT SIZE=-1>N</FONT> F<FONT SIZE=-1>EBRUARY</FONT>
9<FONT SIZE=-1>TH,</FONT> 1995:
</B>
<P>


<UL>The spec has been clarified to indicate the byte order of sequence
numbers when they are being applied to the MAC hash function.

<LI>The spec now defines the acceptable length range of the
<TT>CONNECTION-ID</TT> parameter (sent by the server in the
<TT>SERVER-HELLO</TT> message).

<LI>Simplified the specification of the <TT>CIPHER-KIND</TT> data.
The spec language has been changed yet the format remains compatible
with all existing implementations. The <TT>CIPHER-KIND</TT>
information is now a three byte value which defines the type of cipher
and the length of the key. The key length is no longer separable from
the <TT>CIPHER-KIND</TT>.

<LI>Explained how the <TT>KEY-ARG-DATA</TT> is retained with the
<TT>SESSION-ID</TT> when the session-identifier cache is used.

</UL>

<HR SIZE=8>

<BODY>
<PRE>
Experimental                                             Kipp E.B. Hickman
Request For Comments: XXXX                   Netscape Communications Corp.
Category: Informational                        Last Update: Feb. 9th, 1995
</PRE>

<P>

<center>The SSL Protocol</center> <P>

<H3>Status of this Memo</H3>
<DL>
<DD> 
This is a <B>DRAFT</B> specification. <P>

This RFC specifies a security protocol for the Internet community, and
requests discussion and suggestions for improvements. Distribution of
this memo is unlimited.

</DL>
<H3>Abstract</H3>
<DL><DD>

This document specifies the Secure Sockets Layer (SSL) protocol, a
security protocol that provides privacy over the Internet. The
protocol allows client/server applications to communicate in a way
that cannot be eavesdropped. Server's are always authenticated and
clients are optionally authenticated. <P>

</DL>
<H3>Motivation</H3>
<DL><DD>

The SSL Protocol is designed to provide privacy between two
communicating applications (a client and a server). Second, the
protocol is designed to authenticate the server, and optionally the
client. SSL requires a reliable transport protocol (e.g. TCP) for data
transmission and reception. <P>

The advantage of the SSL Protocol is that it is application protocol
independent. A "higher level" application protocol (e.g. HTTP, FTP,
TELNET, etc.) can layer on top of the SSL Protocol transparently.  The
SSL Protocol can negotiate an encryption algorithm and session key as
well as authenticate a server before the application protocol
transmits or receives its first byte of data. All of the application
protocol data is transmitted encrypted, ensuring privacy. <P>

The SSL protocol provides "channel security" which has three basic
properties: <P>

<UL TYPE=disc>

<LI>The channel is private. Encryption is used for all messages after
a simple handshake is used to define a secret key. <P>

<LI>The channel is authenticated. The server endpoint of the
conversation is always authenticated, while the client endpoint is
optionally authenticated. <P>

<LI>The channel is reliable. The message transport includes a message
integrity check (using a MAC).

</UL>

</DL>
<H3>1. SSL Record Protocol Specification</H3>
<DL><DD>

<H4>1.1 SSL Record Header Format</H4>

In SSL, all data sent is encapsulated in a <B>record</B>, an object
which is composed of a header and some non-zero amount of data.  Each
record header contains a two or three byte length code.  If the most
significant bit is set in the first byte of the record length code
then the record has no padding and the total header length will be 2
bytes, otherwise the record has padding and the total header length
will be 3 bytes. The record header is transmitted before the data
portion of the record. <P>

Note that in the long header case (3 bytes total), the second most
significant bit in the first byte has special meaning. When zero, the
record being sent is a data record. When one, the record being sent is
a security escape (there are currently no examples of security
escapes; this is reserved for future versions of the protocol). In
either case, the length code describes how much data is in the record.
<P>

The record length code does not include the number of bytes consumed
by the record header (2 or 3). For the 2 byte header, the record
length is computed by (using a "C"-like notation): <P>

<PRE>
RECORD-LENGTH = ((byte[0] &amp; 0x7f) &lt;&lt; 8)) | byte[1];
</PRE>

Where byte[0] represents the first byte received and byte[1] the
second byte received.  When the 3 byte header is used, the record
length is computed as follows (using a "C"-like notation): <P>

<PRE>
RECORD-LENGTH = ((byte[0] &amp; 0x3f) &lt;&lt; 8)) | byte[1];
IS-ESCAPE = (byte[0] &amp; 0x40) != 0;
PADDING = byte[2];
</PRE>

The record header defines a value called <tt>PADDING</tt>. The
<TT>PADDING</TT> value specifies how many bytes of data were appended
to the original record by the sender. The padding data is used to make
the record length be a multiple of the block ciphers block size when a
block cipher is used for encryption. <P>

The sender of a "padded" record appends the padding data to the end of
its normal data and then encrypts the total amount (which is now a
multiple of the block cipher's block size). The actual value of the
padding data is unimportant, but the encrypted form of it must be
transmitted for the receiver to properly decrypt the record. Once the
total amount being transmitted is known the header can be properly
constructed with the <TT>PADDING</TT> value set appropriately. <P>

The receiver of a padded record decrypts the entire record data (sans
record length and the optional padding) to get the clear data, then
subtracts the <TT>PADDING</TT> value from the <TT>RECORD-LENGTH</TT>
to determine the final <TT>RECORD-LENGTH</TT>. The clear form of the
padding data must be discarded. <P>

<H4>1.2 SSL Record Data Format</H4>

The data portion of an SSL record is composed of three components
(transmitted and received in the order shown): <P>

<PRE>
MAC-DATA[MAC-SIZE]
ACTUAL-DATA[N]
PADDING-DATA[PADDING]
</PRE>

<TT>ACTUAL-DATA</TT> is the actual data being transmitted (the message
payload). <TT>PADDING-DATA</TT> is the padding data sent when a block
cipher is used and padding is needed. Finally, <TT>MAC-DATA</TT> is
the <I>Message Authentication Code</I>. <P>

When SSL records are sent in the clear, no cipher is used.
Consequently the amount of <TT>PADDING-DATA</TT> will be zero and the
amount of <TT>MAC-DATA</TT> will be zero. When encryption is in
effect, the <TT>PADDING-DATA</TT> will be a function of the cipher
block size. The <TT>MAC-DATA</TT> is a function of the
<TT>CIPHER-CHOICE</TT> (more about that later). <P>

The <TT>MAC-DATA</TT> is computed as follows: <P>

<PRE>
MAC-DATA = HASH[ SECRET, ACTUAL-DATA, PADDING-DATA, SEQUENCE-NUMBER ]
</PRE>

Where the <TT>SECRET</TT> data is fed to the hash function first,
followed by the <TT>ACTUAL-DATA</TT>, which is followed by the
<TT>PADDING-DATA</TT> which is finally followed by the
<TT>SEQUENCE-NUMBER</TT>. The <TT>SEQUENCE-NUMBER</TT> is a 32 bit
value which is presented to the hash function as four bytes, with the
first byte being the most significant byte of the sequence number, the
second byte being the next most significant byte of the sequence
number, the third byte being the third most significant byte, and the
fourth byte being the least significant byte (that is, in network byte
order or "big endian" order).  <P>

<TT>MAC-SIZE</TT> is a function of the digest algorithm being
used. For MD2 and MD5 the <TT>MAC-SIZE</TT> will be 16 bytes (128
bits). <P>

The <TT>SECRET</TT> value is a function of which party is sending the
message. If the client is sending the message then the <TT>SECRET</TT>
is the <TT>CLIENT-WRITE-KEY</TT> (the server will use the
<TT>SERVER-READ-KEY</TT> to verify the MAC). If the client is
receiving the message then the <TT>SECRET</TT> is the
<TT>CLIENT-READ-KEY</TT> (the server will use the
<TT>SERVER-WRITE-KEY</TT> to generate the MAC). <P>

The <TT>SEQUENCE-NUMBER</TT> is a counter which is incremented by both
the sender and the receiver. For each transmission direction, a pair
of counters is kept (one by the sender, one by the receiver). Every
time a message is sent by a sender the counter is incremented.
Sequence numbers are 32 bit unsigned quantities and must wrap to zero
after incrementing past 0xFFFFFFFF. <P>

The receiver of a message uses the expected value of the sequence
number as input into the MAC <TT>HASH</TT> function (the <TT>HASH</TT>
function is chosen from the <TT>CIPHER-CHOICE</TT>). The computed
<TT>MAC-DATA</TT> must agree bit for bit with the transmitted
<TT>MAC-DATA</TT>. If the comparison is not identity then the record
is considered damaged, and it is to be treated as if an "I/O Error"
had occurred (i.e. an unrecoverable error is asserted and the
connection is closed). <P>

A final consistency check is done when a block cipher is used and the
protocol is using encryption. The amount of data present in a record
(<TT>RECORD-LENGTH)</TT>)must be a multiple of the cipher's block
size.  If the received record is not a multiple of the cipher's block
size then the record is considered damaged, and it is to be treated as
if an "I/O Error" had occurred (i.e. an unrecoverable error is asserted
and the connection is closed). <P>

The SSL Record Layer is used for all SSL communications, including
handshake messages, security escapes and application data
transfers. The SSL Record Layer is used by both the client and the
server at all times. <P>

For a two byte header, the maximum record length is 32767 bytes.  For
the three byte header, the maximum record length is 16383 bytes. The
SSL Handshake Protocol messages are constrained to fit in a single SSL
Record Protocol record. Application protocol messages are allowed to
consume multiple SSL Record Protocol record's. <P>

Before the first record is sent using SSL all sequence numbers are
initialized to zero. The transmit sequence number is incremented after
every message sent, starting with the <TT>CLIENT-HELLO</TT> and
<TT>SERVER-HELLO</TT> messages. <P>

</DL>
<H3>2. SSL Handshake Protocol Specification</H3>
<DL><DD>

<H4>2.1 SSL Handshake Protocol Flow</H4>
<DL><DD>

The SSL Handshake Protocol has two major phases. The first phase is
used to establish private communications. The second phase is used for
client authentication. <P>

<H4>Phase 1</H4>

The first phase is the initial connection phase where both parties
communicate their "hello" messages. The client initiates the
conversation by sending the <TT>CLIENT-HELLO</TT> message. The server
receives the <TT>CLIENT-HELLO</TT> message and processes it responding
with the <TT>SERVER-HELLO</TT> message. <P>

At this point both the client and server have enough information to
know whether or not a new master key is needed.  When a new master
key is not needed, both the client and the server proceed immediately
to phase 2. <P>

When a new master key is needed, the <TT>SERVER-HELLO</TT> message
will contain enough information for the client to generate it.  This
includes the server's signed certificate (more about that later), a
list of bulk cipher specifications (see below), and a connection-id (a
connection-id is a randomly generated value generated by the server
that is used by the client and server during a single connection).
The client generates the master key and responds with a
<TT>CLIENT-MASTER-KEY</TT> message (or an <TT>ERROR</TT> message if
the server information indicates that the client and server cannot
agree on a bulk cipher). <P>

It should be noted here that each SSL endpoint uses a pair of ciphers
per connection (for a total of four ciphers). At each endpoint, one
cipher is used for outgoing communications, and one is used for
incoming communications.  When the client or server generate a session
key, they actually generate two keys, the <TT>SERVER-READ-KEY</TT>
(also known as the <TT>CLIENT-WRITE-KEY</TT>) and the
<TT>SERVER-WRITE-KEY</TT> (also known as the
<TT>CLIENT-READ-KEY</TT>). The master key is used by the client and
server to generate the various session keys (more about that
later). <P>

Finally, the server sends a <TT>SERVER-VERIFY</TT> message to the
client after the master key has been determined. This final step
authenticates the server, because only a server which has the
appropriate public key can know the master key. <P>

<H4>Phase 2</H4>

The second phase is the authentication phase. The server has already
been authenticated by the client in the first phase, so this phase is
primarily used to authenticate the client. In a typical scenario, the
server will require something from the client and send a request. The
client will answer in the positive if it has the needed information,
or send an <TT>ERROR</TT> message if it does not. This protocol
specification does not define the semantics of an <TT>ERROR</TT>
response to a server request (e.g., an implementation can ignore the
error, close the connection, etc. and still conform to this
specification). <P>

When a party is done authenticating the other party, it sends its
<B>finished</B> message.  For the client, the <TT>CLIENT-FINISHED</TT>
message contains the encrypted form of the <TT>CONNECTION-ID</TT> for
the server to verify. If the verification fails, the server sends an
ERROR message. <P>

Once a party has sent its <B>finished</B> message it must continue to
listen to its peers messages until it too receives a <B>finished</B>
message. Once a party has both sent a finished message and received
its peers finished message, the SSL handshake protocol is done. At
this point the application protocol begins to operate (Note: the
application protocol continues to be layered on the SSL Record
Protocol). <P>

</DL>
<H4>2.2 Typical Protocol Message Flow</H4>
<DL><DD>

The following sequences define several typical protocol message flows
for the SSL Handshake Protocol. In these examples we have two
principals in the conversation: the client and the server. We use a
notation commonly found in the literature [10]. When something is enclosed
in curly braces "{something}key" then the something has been encrypted
using "key". <P>

<H4>2.2.1 Assuming no session-identifier</H4>

<PRE>
client-hello         C -&gt; S: challenge, cipher_specs
server-hello         S -&gt; C: connection-id,server_certificate,cipher_specs
client-master-key    C -&gt; S: {master_key}server_public_key
client-finish        C -&gt; S: {connection-id}client_write_key
server-verify        S -&gt; C: {challenge}server_write_key
server-finish        S -&gt; C: {new_session_id}server_write_key
</PRE>

<H4>2.2.2 Assuming a session-identifier was found by both client &amp;
server</H4>

<PRE>
client-hello         C -&gt; S: challenge, session_id, cipher_specs
server-hello         S -&gt; C: connection-id, session_id_hit
client-finish        C -&gt; S: {connection-id}client_write_key
server-verify        S -&gt; C: {challenge}server_write_key
server-finish        S -&gt; C: {session_id}server_write_key
</PRE>

<H4>2.2.3 Assuming a session-identifier was used and client
authentication is used</H4>

<PRE>
client-hello         C -&gt; S: challenge, session_id, cipher_specs
server-hello         S -&gt; C: connection-id, session_id_hit
client-finish        C -&gt; S: {connection-id}client_write_key
server-verify        S -&gt; C: {challenge}server_write_key
request-certificate  S -&gt; C: {auth_type,challenge'}server_write_key
client-certificate   C -&gt; S: {cert_type,client_cert,
			      response_data}client_write_key
server-finish        S -&gt; C: {session_id}server_write_key
</PRE>

In this last exchange, the <B>response_data</B> is a function of the
<B>auth_type</B>. <P>

</DL>
<H4>2.3 Errors</H4>
<DL><DD>

Error handling in the SSL connection protocol is very simple.  When an
error is detected, the detecting party sends a message to the other
party. Errors that are not recoverable cause the client and server to
abort the secure connection. Servers and client are required to
"forget" any session-identifiers associated with a failing
connection. <P>

The SSL Handshake Protocol defines the following errors: <P>

<DL>

<DT> NO-CIPHER-ERROR

<DD> This error is returned by the client to the server when it cannot
find a cipher or key size that it supports that is also supported by the
server. This error is not recoverable. <P>

<DT> NO-CERTIFICATE-ERROR

<DD> When a REQUEST-CERTIFICATE message is sent, this error may
be returned if the client has no certificate to reply with.
This error is recoverable (for client authentication only). <P>

<DT> BAD-CERTIFICATE-ERROR

<DD> This error is returned when a certificate is deemed bad by the
receiving party. Bad means that either the signature of the
certificate was bad or that the values in the certificate were
inappropriate (e.g. a name in the certificate did not match the
expected name). This error is recoverable (for client authentication
only). <P>

<DT> UNSUPPORTED-CERTIFICATE-TYPE-ERROR

<DD> This error is returned when a client/server receives a
certificate type that it can't support. This error is recoverable (for
client authentication only). <P>

</DL>

</DL>
<H4>2.4 SSL Handshake Protocol Messages</H4>
<DL><DD>

The SSL Handshake Protocol messages are encapsulated in the SSL Record
Protocol and are composed of two parts: a single byte message type
code, and some data.  The client and server exchange messages until
both ends have sent their "finished" message, indicating that they are
satisfied with the SSL Handshake Protocol conversation. While one end
may be finished, the other may not, therefore the finished end must
continue to receive SSL Handshake Protocol messages until it too
receives a "finished" message. <P>

After the pair of session keys has been determined by each party, the
message bodies are encrypted using it.  For the client, this happens
after it verifies the session-identifier or creates a new session key
and has sent it to the server.  For the server, this happens after the
session-identifier is found to be good, or the server receives the
client's session key message. <P>

The following notation is used for SSLHP messages:

<PRE>
    char MSG-EXAMPLE
    char FIELD1
    char FIELD2
    char THING-MSB
    char THING-LSB
    char THING-DATA[(MSB&lt;&lt;8)|LSB];
    ...
</PRE>

This notation defines the data in the protocol message, including the
message type code. The order is presented top to bottom, with the top
most element being transmitted first, and the bottom most element
transferred last. <P>

For the "THING-DATA" entry, the MSB and LSB values are actually
THING-MSB and THING-LSB (respectively) and define the number of bytes
of data actually present in the message. For example, if THING-MSB
were zero and THING-LSB were 8 then the THING-DATA array would be
exactly 8 bytes long. This shorthand is used below. <P>

Length codes are unsigned values, and when the MSB and LSB are
combined the result is an unsigned value. Unless otherwise specified
lengths values are "length in bytes". <P>

</DL>
<H4>2.5 Client Only Protocol Messages</H4>
<DL><DD>

There are several messages that are only generated by clients. These
messages are never generated by correctly functioning servers. A
client receiving such a message closes the connection to the server
and returns an error status to the application through some
unspecified mechanism. <P>

<H4>CLIENT-HELLO (Phase 1; Sent in the clear)</H4>

<PRE>
    char MSG-CLIENT-HELLO
    char CLIENT-VERSION-MSB
    char CLIENT-VERSION-LSB
    char CIPHER-SPECS-LENGTH-MSB
    char CIPHER-SPECS-LENGTH-LSB
    char SESSION-ID-LENGTH-MSB
    char SESSION-ID-LENGTH-LSB
    char CHALLENGE-LENGTH-MSB
    char CHALLENGE-LENGTH-LSB
    char CIPHER-SPECS-DATA[(MSB&lt;&lt;8)|LSB]
    char SESSION-ID-DATA[(MSB&lt;&lt;8)|LSB]
    char CHALLENGE-DATA[(MSB&lt;&lt;8)|LSB]
</PRE>

When a client first connects to a server it is required to send the
<TT>CLIENT-HELLO</TT> message. The server is expecting this message
from the client as its first message. It is an error for a client to
send anything else as its first message. <P>

The client sends to the server its SSL version, its cipher specs (see
below), some challenge data, and the session-identifier data.  The
session-identifier data is only sent if the client found a
session-identifier in its cache for the server, and the
<TT>SESSION-ID-LENGTH</TT> will be non-zero. When there is no
session-identifier for the server <TT>SESSION-ID-LENGTH</TT> must be
zero. The challenge data is used to authenticate the server. After the
client and server agree on a pair of session keys, the server returns
a <TT>SERVER-VERIFY</TT> message with the encrypted form of the
<TT>CHALLENGE-DATA</TT>. <P>

Also note that the server will not send its <TT>SERVER-HELLO</TT>
message until it has received the <TT>CLIENT-HELLO</TT> message. This
is done so that the server can indicate the status of the client's
session-identifier back to the client in the server's first message
(i.e. to increase protocol efficiency and reduce the number of round
trips required). <P>

The server examines the <TT>CLIENT-HELLO</TT> message and will verify
that it can support the client version and one of the client cipher
specs. The server can optionally edit the cipher specs, removing any
entries it doesn't choose to support. The edited version will be
returned in the <TT>SERVER-HELLO</TT> message if the
session-identifier is not in the server's cache. <P>

The <TT>CIPHER-SPECS-LENGTH</TT> must be greater than zero and a
multiple of 3. The <TT>SESSION-ID-LENGTH</TT> must either be zero or
16.  The <TT>CHALLENGE-LENGTH</TT> must be greater than or equal to 16
and less than or equal to 32. <P>

This message must be the first message sent by the client to the
server. After the message is sent the client waits for a
<TT>SERVER-HELLO</TT> message. Any other message returned by the
server (other than <TT>ERROR</TT>) is disallowed. <P>

<H4>CLIENT-MASTER-KEY (Phase 1; Sent primarily in the clear)</H4>

<PRE>
    char MSG-CLIENT-MASTER-KEY
    char CIPHER-KIND[3]
    char CLEAR-KEY-LENGTH-MSB
    char CLEAR-KEY-LENGTH-LSB
    char ENCRYPTED-KEY-LENGTH-MSB
    char ENCRYPTED-KEY-LENGTH-LSB
    char KEY-ARG-LENGTH-MSB
    char KEY-ARG-LENGTH-LSB
    char CLEAR-KEY-DATA[MSB&lt;&lt;8|LSB]
    char ENCRYPTED-KEY-DATA[MSB&lt;&lt;8|LSB]
    char KEY-ARG-DATA[MSB&lt;&lt;8|LSB]
</PRE>

The client sends this message when it has determined a master key for
the server to use. Note that when a session-identifier has been agreed
upon, this message is not sent. <P>

The <TT>CIPHER-KIND</TT> field indicates which cipher was chosen
from the server's <TT>CIPHER-SPECS</TT>. <P>

The <TT>CLEAR-KEY-DATA</TT> contains the clear portion of the
<TT>MASTER-KEY</TT>. The <TT>CLEAR-KEY-DATA</TT> is combined with the
<TT>SECRET-KEY-DATA</TT> (described shortly) to form the
<TT>MASTER-KEY</TT>, with the <TT>SECRET-KEY-DATA</TT> being the least
significant bytes of the final <TT>MASTER-KEY</TT>.

The <TT>ENCRYPTED-KEY-DATA</TT> contains the secret portions of the
<TT>MASTER-KEY</TT>, encrypted using the server's public key. The
encryption block is formatted using block type 2 from PKCS#1 [5]. The
data portion of the block is formatted as follows: <P>

<PRE>
    char SECRET-KEY-DATA[SECRET-LENGTH]
</PRE>

<TT>SECRET-LENGTH</TT> is the number of bytes of each session key that
is being transmitted encrypted. The <TT>SECRET-LENGTH</TT> plus the
<TT>CLEAR-KEY-LENGTH</TT> equals the number of bytes present in the
cipher key (as defined by the <TT>CIPHER-KIND</TT>). It is an error if
the <TT>SECRET-LENGTH</TT> found after decrypting the PKCS#1 formatted
encryption block doesn't match the expected value.  It is also an
error if <TT>CLEAR-KEY-LENGTH</TT> is non-zero and the
<TT>CIPHER-KIND</TT> is not an export cipher. <P>

If the key algorithm needs an argument (for example, DES-CBC's
initialization vector) then the <TT>KEY-ARG-LENGTH</TT> fields will be
non-zero and the <TT>KEY-ARG-DATA</TT> will contain the relevant
data. For the <TT>SSL_CK_RC2_128_CBC_WITH_MD5</TT>,
<TT>SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5</TT>,
<TT>SSL_CK_IDEA_128_CBC_WITH_MD5</TT>,
<TT>SSL_CK_DES_64_CBC_WITH_MD5</TT> and
<TT>SSL_CK_DES_192_EDE3_CBC_WITH_MD5</TT> algorithms the <TT>KEY-ARG</TT>
data must be present and be exactly 8 bytes long. <P>

Client and server session key production is a function of the
<TT>CIPHER-CHOICE</TT>: <P>

<DL>
<DT> <B>SSL_CK_RC4_128_WITH_MD5</B>
<DT> <B>SSL_CK_RC4_128_EXPORT40_WITH_MD5</B>
<DT> <B>SSL_CK_RC2_128_CBC_WITH_MD5</B>
<DT> <B>SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5</B>
<DT> <B>SSL_CK_IDEA_128_CBC_WITH_MD5</B>

<DD> 

<PRE>
KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]
KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]

CLIENT-READ-KEY = KEY-MATERIAL-0[0-15]
CLIENT-WRITE-KEY = KEY-MATERIAL-1[0-15]
</PRE>

Where <TT>KEY-MATERIAL-0[0-15]</TT> means the first 16 bytes of the
<TT>KEY-MATERIAL-0</TT> data, with <TT>KEY-MATERIAL-0[0]</TT> becoming
the most significant byte of the <TT>CLIENT-READ-KEY</TT>.  <P>

Data is fed to the MD5 hash function in the order shown, from left to
right: first the <TT>MASTER-KEY</TT>, then the "0" or "1", then the
<TT>CHALLENGE</TT> and then finally the <TT>CONNECTION-ID</TT>. <P>

Note that the "0" means the ascii zero character (0x30), not a zero
value. "1" means the ascii 1 character (0x31). MD5 produces 128 bits
of output data which are used directly as the key to the cipher
algorithm (The most significant byte of the MD5 output becomes the
most significant byte of the key material). <P>

<DT> <B>SSL_CK_DES_64_CBC_WITH_MD5</B>

<DD> 

<PRE>
KEY-MATERIAL-0 = MD5[ MASTER-KEY, CHALLENGE, CONNECTION-ID ]

CLIENT-READ-KEY = KEY-MATERIAL-0[0-7]
CLIENT-WRITE-KEY = KEY-MATERIAL-0[8-15]
</PRE>

For DES-CBC, a single 16 bytes of key material are produced using MD5.
The first 8 bytes of the MD5 digest are used as the
<TT>CLIENT-READ-KEY</TT> while the remaining 8 bytes are used as the
<TT>CLIENT-WRITE-KEY</TT>. The initialization vector is provided in
the <TT>KEY-ARG-DATA</TT>. Note that the raw key data is not parity
adjusted and that this step must be performed before the keys are
legitimate DES keys. <P>

<DT> <B>SSL_CK_DES_192_EDE3_CBC_WITH_MD5</B>

<DD> 

<PRE>
KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]
KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]
KEY-MATERIAL-2 = MD5[ MASTER-KEY, "2", CHALLENGE, CONNECTION-ID ]

CLIENT-READ-KEY-0 = KEY-MATERIAL-0[0-7]
CLIENT-READ-KEY-1 = KEY-MATERIAL-0[8-15]
CLIENT-READ-KEY-2 = KEY-MATERIAL-1[0-7]
CLIENT-WRITE-KEY-0 = KEY-MATERIAL-1[8-15] 
CLIENT-WRITE-KEY-1 = KEY-MATERIAL-2[0-7] 
CLIENT-WRITE-KEY-2 = KEY-MATERIAL-2[8-15] 
</PRE>

Data is fed to the MD5 hash function in the order shown, from left to
right: first the <TT>MASTER-KEY</TT>, then the "0", "1" or "2", then
the <TT>CHALLENGE</TT> and then finally the <TT>CONNECTION-ID</TT>. <P>

Note that the "0" means the ascii zero character (0x30), not a zero
value. "1" means the ascii 1 character (0x31). "2" means the ascii 2
character (0x32). <P>

A total of 6 keys are produced, 3 for the read side DES-EDE3 cipher
and 3 for the write side DES-EDE3 function. The initialization vector
is provided in the <TT>KEY-ARG-DATA</TT>. The keys that are produced
are not parity adjusted. This step must be performed before proper DES
keys are usable. <P>

</DL> <P>

Recall that the <TT>MASTER-KEY</TT> is given to the server in the
<TT>CLIENT-MASTER-KEY</TT> message. The <TT>CHALLENGE</TT> is given
to the server by the client in the <TT>CLIENT-HELLO</TT> message. The
<TT>CONNECTION-ID</TT> is given to the client by the server in the
<TT>SERVER-HELLO</TT> message. This makes the resulting cipher keys a
function of the original session and the current session. Note that
the master key is never directly used to encrypt data, and therefore
cannot be easily discovered. <P>

The <TT>CLIENT-MASTER-KEY</TT> message must be sent after the
<TT>CLIENT-HELLO</TT> message and before the <TT>CLIENT-FINISHED</TT>
message. The <TT>CLIENT-MASTER-KEY</TT> message must be sent if the
<TT>SERVER-HELLO</TT> message contains a <TT>SESSION-ID-HIT</TT> value
of 0. <P>

<H4>CLIENT-CERTIFICATE (Phase 2; Sent encrypted)</H4>

<PRE>
    char MSG-CLIENT-CERTIFICATE
    char CERTIFICATE-TYPE
    char CERTIFICATE-LENGTH-MSB
    char CERTIFICATE-LENGTH-LSB
    char RESPONSE-LENGTH-MSB
    char RESPONSE-LENGTH-LSB
    char CERTIFICATE-DATA[MSB&lt;&lt;8|LSB]
    char RESPONSE-DATA[MSB&lt;&lt;8|LSB]
</PRE>

This message is sent by one an SSL client in response to a server
<TT>REQUEST-CERTIFICATE</TT> message. The <TT>CERTIFICATE-DATA</TT>
contains data defined by the <TT>CERTIFICATE-TYPE</TT> value. An
<TT>ERROR</TT> message is sent with error code
<TT>NO-CERTIFICATE-ERROR</TT> when this request cannot be answered
properly (e.g. the receiver of the message has no registered
certificate). <P>

<TT>CERTIFICATE-TYPE</TT> is one of: <P>

<DL>
<DT> <B>SSL_X509_CERTIFICATE</B>
<DD> The <TT>CERTIFICATE-DATA</TT> contains an X.509 (1988) [3] signed
certificate. <P>
</DL>

The <TT>RESPONSE-DATA</TT> contains the authentication response data.
This data is a function of the <TT>AUTHENTICATION-TYPE</TT> value sent
by the server. <P>

When <TT>AUTHENTICATION-TYPE</TT> is
<TT>SSL_AT_MD5_WITH_RSA_ENCRYPTION</TT> then the
<TT>RESPONSE-DATA</TT> contains a digital signature of the following
components (in the order shown): <P>

<UL TYPE=disc>
<LI>the KEY-MATERIAL-0
<LI>the KEY-MATERIAL-1 (only if defined by the cipher kind)
<LI>the KEY-MATERIAL-2 (only if defined by the cipher kind)
<LI>the CERTIFICATE-CHALLENGE-DATA (from the REQUEST-CERTIFICATE message)
<LI>the server's signed certificate (from the SERVER-HELLO message)
</UL> <P>

The digital signature is constructed using MD5 and then encrypted
using the clients private key, formatted according to PKCS#1's digital
signature standard [5]. The server authenticates the client by
verifying the digital signature using standard techniques. Note that
other digest functions are supported. Either a new
<TT>AUTHENTICATION-TYPE</TT> can be added, or the algorithm-id in the
digital signature can be changed. <P>

This message must be sent by the client only in response to a
<TT>REQUEST-CERTIFICATE</TT> message. <P>

<H4>CLIENT-FINISHED (Phase 2; Sent encrypted)</H4>

<PRE>
    char MSG-CLIENT-FINISHED
    char CONNECTION-ID[N-1]
</PRE>

The client sends this message when it is satisfied with the server.
Note that the client must continue to listen for server messages until
it receives a <TT>SERVER-FINISHED</TT> message. The
<TT>CONNECTION-ID</TT> data is the original connection-identifier the
server sent with its <TT>SERVER-HELLO</TT> message, encrypted using
the agreed upon session key. <P>

"<TT>N</TT>" is the number of bytes in the message that was sent, so
"<TT>N-1</TT>" is the number of bytes in the message without the
message header byte. <P>

For version 2 of the protocol, the client must send this message after
it has received the <TT>SERVER-HELLO</TT> message. If the
<TT>SERVER-HELLO</TT> message <TT>SESSION-ID-HIT</TT> flag is non-zero
then the <TT>CLIENT-FINISHED</TT> message is sent immediately,
otherwise the <TT>CLIENT-FINISHED</TT> message is sent after the
<TT>CLIENT-MASTER-KEY</TT> message. <P>

</DL>
<H4>2.6 Server Only Protocol Messages</H4>
<DL><DD>

There are several messages that are only generated by servers. The
messages are never generated by correctly functioning clients. <P>

<H4>SERVER-HELLO (Phase 1; Sent in the clear)</H4>

<PRE>
    char MSG-SERVER-HELLO
    char SESSION-ID-HIT
    char CERTIFICATE-TYPE
    char SERVER-VERSION-MSB
    char SERVER-VERSION-LSB
    char CERTIFICATE-LENGTH-MSB
    char CERTIFICATE-LENGTH-LSB
    char CIPHER-SPECS-LENGTH-MSB
    char CIPHER-SPECS-LENGTH-LSB
    char CONNECTION-ID-LENGTH-MSB
    char CONNECTION-ID-LENGTH-LSB
    char CERTIFICATE-DATA[MSB&lt;&lt;8|LSB]
    char CIPHER-SPECS-DATA[MSB&lt;&lt;8|LSB]
    char CONNECTION-ID-DATA[MSB&lt;&lt;8|LSB]
</PRE>

The server sends this message after receiving the clients
<TT>CLIENT-HELLO</TT> message. The server returns the
<TT>SESSION-ID-HIT</TT> flag indicating whether or not the received
session-identifier is known by the server (i.e. in the server's
session-identifier cache). The <TT>SESSION-ID-HIT</TT> flag will be
non-zero if the client sent the server a session-identifier (in the
<TT>CLIENT-HELLO</TT> message with <TT>SESSION-ID-LENGTH</TT> != 0)
and the server found the client's session-identifier in its cache. If
the <TT>SESSION-ID-HIT</TT> flag is non-zero then the
<TT>CERTIFICATE-TYPE</TT>, <TT>CERTIFICATE-LENGTH</TT> and
<TT>CIPHER-SPECS-LENGTH</TT> fields will be zero. <P>

The <TT>CERTIFICATE-TYPE</TT> value, when non-zero, has one of the
values described above (see the information on the
<TT>CLIENT-CERTIFICATE</TT> message). <P>

When the <TT>SESSION-ID-HIT</TT> flag is zero, the server packages up
its certificate, its cipher specs and a connection-id to send to the
client. Using this information the client can generate a session key
and return it to the server with the <TT>CLIENT-MASTER-KEY</TT>
message. <P>

When the <TT>SESSION-ID-HIT</TT> flag is non-zero, both the server and
the client compute a new pair of session keys for the current session
derived from the <TT>MASTER-KEY</TT> that was exchanged when the
<TT>SESSION-ID</TT> was created. The <TT>SERVER-READ-KEY</TT> and
<TT>SERVER-WRITE-KEY</TT> are derived from the original
<TT>MASTER-KEY</TT> keys in the same manner as the <TT>CLIENT-READ-KEY</TT>
and <TT>CLIENT-WRITE-KEY</TT>:

<PRE>
SERVER-READ-KEY = CLIENT-WRITE-KEY
SERVER-WRITE-KEY = CLIENT-READ-KEY
</PRE>

Note that when keys are being derived and the <TT>SESSION-ID-HIT</TT>
flag is set and the server discovers the client's session-identifier
in the servers cache, then the <TT>KEY-ARG-DATA</TT> is used from the
time when the <TT>SESSION-ID</TT> was established. This is because the
client does not send new <TT>KEY-ARG-DATA</TT> (recall that the
<TT>KEY-ARG-DATA</TT> is sent only in the <TT>CLIENT-MASTER-KEY</TT>
message). <P>

The <TT>CONNECTION-ID-DATA</TT> is a string of randomly generated
bytes used by the server and client at various points in the
protocol. The <TT>CLIENT-FINISHED</TT> message contains an encrypted
version of the <TT>CONNECTION-ID-DATA</TT>. The length of the
<TT>CONNECTION-ID</TT> must be between 16 and than 32 bytes,
inclusive. <P>

The <TT>CIPHER-SPECS-DATA</TT> define a cipher type and key length (in
bits) that the receiving end supports. Each
<TT>SESSION-CIPHER-SPEC</TT> is 3 bytes long and looks like this: <P>

<PRE>
    char CIPHER-KIND-0
    char CIPHER-KIND-1
    char CIPHER-KIND-2
</PRE>

Where CIPHER-KIND is one of: <P>

<UL TYPE=disc>
<LI>SSL_CK_RC4_128_WITH_MD5
<LI>SSL_CK_RC4_128_EXPORT40_WITH_MD5
<LI>SSL_CK_RC2_128_CBC_WITH_MD5
<LI>SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
<LI>SSL_CK_IDEA_128_CBC_WITH_MD5
<LI>SSL_CK_DES_64_CBC_WITH_MD5
<LI>SSL_CK_DES_192_EDE3_CBC_WITH_MD5
</UL>
<P>

This list is not exhaustive and may be changed in the future. <P>

The <TT>SSL_CK_RC4_128_EXPORT40_WITH_MD5</TT> cipher is an RC4 cipher
where some of the session key is sent in the clear and the rest is
sent encrypted (exactly 40 bits of it). MD5 is used as the hash
function for production of MAC's and session key's. This cipher type
is provided to support "export" versions (i.e. versions of the
protocol that can be distributed outside of the United States) of the
client or server. <P>

An exportable implementation of the SSL Handshake Protocol will have
secret key lengths restricted to 40 bits. For non-export
implementations key lengths can be more generous (we recommend at
least 128 bits). It is permissible for the client and server to have a
non-intersecting set of stream ciphers. This, simply put, means they
cannot communicate. <P>

Version 2 of the SSL Handshake Protocol defines the
<TT>SSL_CK_RC4_128_WITH_MD5</TT> to have a key length of 128 bits. The
<TT>SSL_CK_RC4_128_EXPORT40_WITH_MD5</TT> also has a key length of 128
bits. However, only 40 of the bits are secret (the other 88 bits are
sent in the clear by the client to the server). <P>

The <TT>SERVER-HELLO</TT> message is sent after the server receives
the <TT>CLIENT-HELLO</TT> message, and before the server sends the
<TT>SERVER-VERIFY</TT> message. <P>

<H4>SERVER-VERIFY (Phase 1; Sent encrypted)</H4>

<PRE>
    char MSG-SERVER-VERIFY
    char CHALLENGE-DATA[N-1]
</PRE>

The server sends this message after a pair of session keys
(<TT>SERVER-READ-KEY</TT> and <TT>SERVER-WRITE-KEY</TT>) have been
agreed upon either by a session-identifier or by explicit
specification with the <TT>CLIENT-MASTER-KEY</TT> message. The
message contains an encrypted copy of the <TT>CHALLENGE-DATA</TT> sent
by the client in the <TT>CLIENT-HELLO</TT> message. <P>

"<TT>N</TT>" is the number of bytes in the message that was sent, so
"<TT>N-1</TT>" is the number of bytes in the <TT>CHALLENGE-DATA</TT>
without the message header byte. <P>

This message is used to verify the server as follows. A legitimate
server will have the private key that corresponds to the public key
contained in the server certificate that was transmitted in the
<TT>SERVER-HELLO</TT> message. Accordingly, the legitimate server will
be able to extract and reconstruct the pair of session keys
(<TT>SERVER-READ-KEY</TT> and <TT>SERVER-WRITE-KEY</TT>). Finally,
only a server that has done the extraction and decryption properly can
correctly encrypt the <TT>CHALLENGE-DATA</TT>. This, in essence,
"proves" that the server has the private key that goes with the public
key in the server's certificate. <P>

The <TT>CHALLENGE-DATA</TT> must be the exact same length as
originally sent by the client in the <TT>CLIENT-HELLO</TT>
message. Its value must match exactly the value sent in the clear by
the client in the <TT>CLIENT-HELLO</TT> message. The client must
decrypt this message and compare the value received with the value
sent, and only if the values are identical is the server to be
"trusted". If the lengths do not match or the value doesn't match then
the connection is to be closed by the client. <P>

This message must be sent by the server to the client after either
detecting a session-identifier hit (and replying with a
<TT>SERVER-HELLO</TT> message with <TT>SESSION-ID-HIT</TT> not equal
to zero) or when the server receives the <TT>CLIENT-MASTER-KEY</TT>
message. This message must be sent before any Phase 2 messages or a
<TT>SEVER-FINISHED</TT> message. <P>

<H4>SERVER-FINISHED (Phase 2; Sent encrypted)</H4>

<PRE>
    char MSG-SERVER-FINISHED
    char SESSION-ID-DATA[N-1]
</PRE>

The server sends this message when it is satisfied with the clients
security handshake and is ready to proceed with transmission/reception
of the higher level protocols data. The <TT>SESSION-ID-DATA</TT> is
used by the client and the server at this time to add entries to their
respective session-identifier caches. The session-identifier caches
must contain a copy of the <TT>MASTER-KEY</TT> sent in the
<TT>CLIENT-MASTER-KEY</TT> message as the master key is used for all
subsequent session key generation. <P>

"<TT>N</TT>" is the number of bytes in the message that was sent, so
"<TT>N-1</TT>" is the number of bytes in the <TT>SESSION-ID-DATA</TT>
without the message header byte. <P>

This message must be sent after the <TT>SERVER-VERIFY</TT>
message. <P>

<H4>REQUEST-CERTIFICATE (Phase 2; Sent encrypted)</H4>

<PRE>
    char MSG-REQUEST-CERTIFICATE
    char AUTHENTICATION-TYPE
    char CERTIFICATE-CHALLENGE-DATA[N-2]
</PRE>

A server may issue this request at any time during the second phase of
the connection handshake, asking for the client's certificate.  The
client responds with a <TT>CLIENT-CERTIFICATE</TT> message immediately
if it has one, or an <TT>ERROR</TT> message (with error code
<TT>NO-CERTIFICATE-ERROR</TT>) if it doesn't. The
<TT>CERTIFICATE-CHALLENGE-DATA</TT> is a short byte string (whose
length is greater than or equal to 16 bytes and less than or equal to
32 bytes) that the client will use to respond to this message. <P>

The <TT>AUTHENTICATION-TYPE</TT> value is used to choose a particular
means of authenticating the client. The following types are defined:
<P>

<UL TYPE=disc>
<LI>SSL_AT_MD5_WITH_RSA_ENCRYPTION
</UL>
<P>

The <TT>SSL_AT_MD5_WITH_RSA_ENCRYPTION</TT> type requires that the
client construct an MD5 message digest using information as described
above in the section on the CLIENT-CERTIFICATE message. Once the
digest is created, the client encrypts it using its private key
(formatted according to the digital signature standard defined in
PKCS#1). The server authenticates the client when it receives the
<TT>CLIENT-CERTIFICATE</TT> message. <P>

This message may be sent after a <TT>SERVER-VERIFY</TT> message and
before a <TT>SERVER-FINISHED</TT> message. <P>

</DL>
<H4>2.7 Client/Server Protocol Messages</H4>
<DL><DD>

These messages are generated by both the client and the server. <P>

<H4>ERROR (Sent clear or encrypted)</H4>

<PRE>
    char MSG-ERROR
    char ERROR-CODE-MSB
    char ERROR-CODE-LSB
</PRE>

This message is sent when an error is detected. After the message
is sent, the sending party shuts the connection down. The receiving
party records the error and then shuts its connection down. <P>

This message is sent in the clear if an error occurs during session
key negotiation. After a session key has been agreed upon, errors are
sent encrypted like all other messages. <P>

</DL>
</DL>

<hr>

<H3>Appendix A: ASN.1 Syntax For Certificates</H3>
<DL><DD>

Certificates are used by SSL to authenticate servers and clients.  SSL
Certificates are based largely on the X.509 [3] certificates. An X.509
certificate contains the following information (in ASN.1 [1] notation): <P>

<PRE>
X.509-Certificate ::= SEQUENCE {
    certificateInfo CertificateInfo,
    signatureAlgorithm AlgorithmIdentifier,
    signature BIT STRING
}

CertificateInfo ::= SEQUENCE {
    version [0] Version DEFAULT v1988,
    serialNumber CertificateSerialNumber,
    signature AlgorithmIdentifier,
    issuer Name,
    validity Validity,
    subject Name,
    subjectPublicKeyInfo SubjectPublicKeyInfo
}

Version ::= INTEGER { v1988(0) }

CertificateSerialNumber ::= INTEGER

Validity ::= SEQUENCE {
    notBefore UTCTime,
    notAfter UTCTime
}

SubjectPublicKeyInfo ::= SEQUENCE {
    algorithm AlgorithmIdentifier,
    subjectPublicKey BIT STRING
}

AlgorithmIdentifier ::= SEQUENCE {
    algorithm OBJECT IDENTIFIER,
    parameters ANY DEFINED BY ALGORITHM OPTIONAL
}
</PRE>

For SSL's purposes we restrict the values of some of the X.509 fields: <P>

<UL TYPE=disc>

<LI>The <TT>X.509-Certificate::signatureAlgorithm</TT> and
<TT>CertificateInfo::signature</TT> fields must be identical in
value. <P>

<LI>The issuer name must resolve to a name that is deemed acceptable
by the application using SSL. How the application using SSL does this
is outside the scope of this memo. <P>

</UL>
<A NAME="#cert-check"></A>
Certificates are validated using a few straightforward steps. First,
the signature on the certificate is checked and if invalid, the
certificate is invalid (either a transmission error or an attempted
forgery occurred). Next, the <TT>CertificateInfo::issuer</TT> field is
verified to be an issuer that the application trusts (using an
unspecified mechanism). The <TT>CertificateInfo::validity</TT> field
is checked against the current date and verified.  <P>

Finally, the <TT>CertificateInfo::subject</TT> field is checked. This
check is optional and depends on the level of trust required by the
application using SSL. <P>

</DL>
<H3>Appendix B: Attribute Types and Object Identifiers</H3>
<DL><DD>

SSL uses a subset of the X.520 selected attribute types as well as a
few specific object identifiers. Future revisions of the SSL protocol
may include support for more attribute types and more object
identifiers. <P>

<H4>B.1 Selected attribute types</H4>

<DL>

<DT> commonName { attributeType 3 }
<DD> The common name contained in the distinguished name contained
within a certificate issuer or certificate subject. <P>

<DT> countryName { attributeType 6 }
<DD> The country name contained in the distinguished name contained
within a certificate issuer or certificate subject. <P>

<DT> localityName { attributeType 7 }
<DD> The locality name contained in the distinguished name contained
within a certificate issuer or certificate subject. <P>

<DT> stateOrProvinceName { attributeType 8 }
<DD> The state or province name contained in the distinguished name
contained within a certificate issuer or certificate subject. <P>

<DT> organizationName { attributeType 10 }
<DD> The organization name contained in the distinguished name
contained within a certificate issuer or certificate subject. <P>

<DT> organizationalUnitName { attributeType 11 }
<DD> The organizational unit name contained in the distinguished name
contained within a certificate issuer or certificate subject. <P>

</DL>

<H4>B.2 Object identifiers</H4>

<DL>

<DT> md2withRSAEncryption { ... pkcs(1) 1 2 }
<DD> The object identifier for digital signatures that use both MD2 and
RSA encryption. Used by SSL for certificate signature verification. <P>

<DT> md5withRSAEncryption { ... pkcs(1) 1 4 }
<DD> The object identifier for digital signatures that use both MD5 and
RSA encryption. Used by SSL for certificate signature verification. <P>

<DT> rc4 { ... rsadsi(113549) 3 4 }
<DD> The RC4 symmetric stream cipher algorithm used by SSL for bulk
encryption. <P>

</DL>

</DL>
<H3>Appendix C: Protocol Constant Values</H3>
<DL><DD>

This section describes various protocol constants. A special value
needs mentioning - the IANA reserved port number for <B>"https"</B>
(HTTP using SSL). IANA has reserved port number 443 (decimal) for
"https". <P>

<H4>C.1 Protocol Version Codes</H4>

<DL><DD><PRE>
#define SSL_CLIENT_VERSION			0x0002
#define SSL_SERVER_VERSION			0x0002
</PRE></DL>

<H4>C.2 Protocol Message Codes</H4>

The following values define the message codes that are used by version
2 of the SSL Handshake Protocol.  <P>

<DL><DD><PRE>
#define SSL_MT_ERROR				0
#define SSL_MT_CLIENT_HELLO			1
#define SSL_MT_CLIENT_MASTER_KEY		2
#define SSL_MT_CLIENT_FINISHED			3
#define SSL_MT_SERVER_HELLO			4
#define SSL_MT_SERVER_VERIFY			5
#define SSL_MT_SERVER_FINISHED			6
#define SSL_MT_REQUEST_CERTIFICATE		7
#define SSL_MT_CLIENT_CERTIFICATE		8
</PRE></DL>

<H4>C.3 Error Message Codes</H4>

The following values define the error codes used by the <TT>ERROR</TT>
message. <P>

<DL><DD><PRE>
#define SSL_PE_NO_CIPHER			0x0001
#define SSL_PE_NO_CERTIFICATE			0x0002
#define SSL_PE_BAD_CERTIFICATE			0x0004
#define SSL_PE_UNSUPPORTED_CERTIFICATE_TYPE	0x0006
</PRE></DL>

<H4>C.4 Cipher Kind Values</H4>

The following values define the <TT>CIPHER-KIND</TT> codes used in the
<TT>CLIENT-HELLO</TT> and <TT>SERVER-HELLO</TT> messages. <P>

<DL><DD><PRE>
#define SSL_CK_RC4_128_WITH_MD5			0x01,0x00,0x80
#define SSL_CK_RC4_128_EXPORT40_WITH_MD5	0x02,0x00,0x80
#define SSL_CK_RC2_128_CBC_WITH_MD5		0x03,0x00,0x80
#define SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5	0x04,0x00,0x80
#define SSL_CK_IDEA_128_CBC_WITH_MD5		0x05,0x00,0x80
#define SSL_CK_DES_64_CBC_WITH_MD5		0x06,0x00,0x40
#define SSL_CK_DES_192_EDE3_CBC_WITH_MD5	0x07,0x00,0xC0
</PRE></DL>

<H4>C.5 Certificate Type Codes</H4>

The following values define the certificate type codes used in the
<TT>SERVER-HELLO</TT> and <TT>CLIENT-CERTIFICATE</TT> messages. <P>

<DL><DD><PRE>
#define SSL_CT_X509_CERTIFICATE			0x01
</PRE></DL>

<H4>C.6 Authentication Type Codes</H4>

The following values define the authentication type codes used in
the <TT>REQUEST-CERTIFICATE</TT> message. <P>

<DL><DD><PRE>
#define SSL_AT_MD5_WITH_RSA_ENCRYPTION		0x01
</PRE></DL>

<H4>C.7 Upper/Lower Bounds</H4>

The following values define upper/lower bounds for various protocol
parameters. <P>

<DL><DD><PRE>
#define SSL_MAX_MASTER_KEY_LENGTH_IN_BITS	256
#define SSL_MAX_SESSION_ID_LENGTH_IN_BYTES	16
#define SSL_MIN_RSA_MODULUS_LENGTH_IN_BYTES	64
#define SSL_MAX_RECORD_LENGTH_2_BYTE_HEADER	32767
#define SSL_MAX_RECORD_LENGTH_3_BYTE_HEADER	16383
</PRE></DL>

<H4>C.8 Recommendations</H4>

Because protocols have to be implemented to be of value, we recommend
the following values for various operational parameters. This is only
a recommendation, and not a strict requirement for conformance to the
protocol. <P>

<DL>

<DT> Session-identifier Cache Timeout <P>

<DD> Session-identifiers are kept in SSL clients and SSL
servers. Session-identifiers should have a lifetime that serves their
purpose (namely, reducing the number of expensive public key
operations for a single client/server pairing). Consequently, we
recommend a maximum session-identifier cache timeout value of 100
seconds. Given a server that can perform N private key operations per
second, this reduces the server load for a particular client by a
factor of 100. <P>

</DL>

</DL>
<H3>Appendix D: Attacks</H3>
<DL><DD>

In this section we attempt to describe various attacks that might
be used against the SSL protocol. This list is not guaranteed to
be exhaustive. SSL was defined to thwart these attacks. <P>

<H4>D.1 Cracking Ciphers</H4>

SSL depends on several cryptographic technologies. RSA Public Key
encryption [5] is used for the exchange of the session key and
client/server authentication. Various cryptographic algorithms are
used for the session cipher. If successful cryptographic attacks are
made against these technologies then SSL is no longer secure. <P>

Attacks against a specific communications session can be made by
recording the session, and then spending some large number of compute
cycles to crack either the session key or the RSA public key until the
communication can be seen in the clear. This approach is easier than
cracking the cryptographic technologies for all possible messages.
Note that SSL tries to make the cost of such of an attack greater than
the benefits gained from a successful attack, thus making it a waste
of money/time to perform such an attack. <P>

There have been many books [9] and papers [10] written on
cryptography.  This document does not attempt to reference them
all. <P>

<H4>D.2 Clear Text Attack</H4>

A clear text attack is done when the attacker has an idea of what kind
of message is being sent using encryption. The attacker can generate a
data base whose keys are the encrypted value of the known text (or
clear text), and whose values are the session cipher key (we call this
a "dictionary"). Once this data base is constructed, a simple lookup
function identifies the session key that goes with a particular
encrypted value. Once the session key is known, the entire message
stream can be decrypted. Custom hardware can be used to make this cost
effective and very fast. <P>

Because of the very nature of SSL clear text attacks are possible. For
example, the most common byte string sent by an HTTP client
application to an HTTP server is "GET". SSL attempts to address this
attack by using large session cipher keys. First, the client generates
a key which is larger than allowed by export, and sends some of it in
the clear to the server (this is allowed by United States government
export rules). The clear portion of the key concatenated with the
secret portion make a key which is very large (for RC4, exactly 128
bits). <P>

The way that this "defeats" a clear text attack is by making the
amount of custom hardware needed prohibitively large. Every bit added
to the length of the session cipher key increases the dictionary size
by a factor of 2. By using a 128 bit session cipher key length the
size of the dictionary required is beyond the ability of anyone to
fabricate (it would require more atoms to construct than exist in the
entire universe). Even if a smaller dictionary is to be used, it must
first be generated using the clear key bits. This is a time
consumptive process and also eliminates many possible custom hardware
architectures (e.g. static prom arrays). <P>

The second way that SSL attacks this problem is by using large key
lengths when permissible (e.g. in the non-export version). Large key
sizes require larger dictionaries (just one more bit of key size
doubles the size of the dictionary). SSL attempts to use keys that are
128 bits in length. <P>

Note that the consequence of the SSL defense is that a brute force
attack becomes the cheapest way to attack the key. Brute force attacks
have well known space/time tradeoffs and so it becomes possible to
define a cost of the attack. For the 128 bit secret key, the known
cost is essentially infinite. For the 40 bit secret key, the cost is
much smaller, but still outside the range of the "random hacker". <P>

<H4>D.3 Replay</H4>

The replay attack is simple. A bad-guy records a communication session
between a client and server. Later, it reconnects to the server, and
plays back the previously recorded client messages. <P>

SSL defeats this attack using a "nonce" (the connection-id) which is
"unique" to the connection. In theory the bad-guy cannot predict the
nonce in advance as it is based on a set of random events outside the
bad-guys control, and therefore the bad-guy cannot respond properly to
server requests. <P>

A bad-guy with large resources can record many sessions between a
client and a server, and attempt to choose the right session based on
the nonce the server sends initially in its SERVER-HELLO message.
However, SSL nonces are at least 128 bits long, so a bad-guy would
need to record approximately 2^64 nonces to even have a 50% chance of
choosing the right session. This number is sufficiently large that one
cannot economically construct a device to record 2^64 messages, and
therefore the odds are overwhelmingly against the replay attack ever
being successful. <P>

<H4>D.4 The Man In The Middle</H4>

The man in the middle attack works by having three people in
a communications session: the client, the server, and the bad guy.
The bad guy sits between the client and the server on the network
and intercepts traffic that the client sends to the server, and
traffic that the server sends to the client. <P>

The man in the middle operates by pretending to be the real server to
the client. With SSL this attack is impossible because of the usage of
server certificates. During the security connection handshake the
server is required to provide a certificate that is signed by a
certificate authority. Contained in the certificate is the server's
public key as well as its name and the name of the certificate
issuer. The client verifies the certificate by first checking the
signature and then verifying that the name of the issuer is somebody
that the client trusts.  <P>

In addition, the server must encrypt something with the private key
that goes with the public key mentioned in the certificate. This in
essence is a single pass "challenge response" mechanism. Only a server
that has both the certificate and the private key can respond properly
to the challenge. <P>

If the man in the middle provides a phony certificate, then the
signature check will fail. If the certificate provided by the bad guy
is legitimate, but for the bad guy instead of for the real server,
then the signature will pass but the name check will fail (note that
the man in the middle cannot forge certificates without discovering a
certificate authority's private key). <P>

Finally, if the bad guy provides the real server's certificate then
the signature check will pass and the name check will pass. However,
because the bad guy does not have the real server's private key, the
bad guy cannot properly encode the response to the challenge code, and
this check will fail. <P>

In the unlikely case that a bad guy happens to guess the response code
to the challenge, the bad guy still cannot decrypt the session key and
therefore cannot examine the encrypted data. <P>

</DL>
<H3>Appendix E: Terms</H3>
<DL><DD>

<DL>

<DT> <B>Application Protocol</B>

<DD> An application protocol is a protocol that normally layers directly
on top of TCP/IP. For example: HTTP, TELNET, FTP, and SMTP. <P>

<DT> <B>Authentication</B>

<DD> Authentication is the ability of one entity to determine the
identity of another entity. Identity is defined by this document to
mean the binding between a <I>public key</I> and a name and the
implicit ownership of the corresponding <I>private key</I>. <P>

<DT> <B>Bulk Cipher</B>

<DD> This term is used to describe a cryptographic technique with
certain performance properties. Bulk ciphers are used when large
quantities of data are to be encrypted/decrypted in a timely
manner. Examples include RC2, RC4, and IDEA. <P>

<DT> <B>Client</B>

<DD> In this document <B>client</B> refers to the application entity
that is initiates a connection to a server. <P>

<DT> <B>CLIENT-READ-KEY</B>

<DD> The session key that the client uses to initialize the client
read cipher. This key has the same value as the SERVER-WRITE-KEY. <P>

<DT> <B>CLIENT-WRITE-KEY</B>

<DD> The session key that the client uses to initialize the client
write cipher. This key has the same value as the SERVER-READ-KEY. <P>

<DT> <B>MASTER-KEY</B>

<DD> The master key that the client and server use for all session
key generation. The CLIENT-READ-KEY, CLIENT-WRITE-KEY, SERVER-READ-KEY
and SERVER-WRITE-KEY are generated from the MASTER-KEY. <P>

<DT> <B>MD2</B>

<DD> MD2 [8] is a hashing function that converts an arbitrarily long
data stream into a <B>digest</B> of fixed size. This function predates
MD5 [7] which is viewed as a more robust hash function [9]. <P>

<DT> <B>MD5</B>

<DD> MD5 [7] is a hashing function that converts an arbitrarily long
data stream into a <B>digest</B> of fixed size. The function has
certain properties that make it useful for security, the most
important of which is it's inability to be reversed. <P>

<DT> <B>Nonce</B>

<DD> A randomly generated value used to defeat "playback" attacks.
One party randomly generates a nonce and sends it to the other party.
The receiver encrypts it using the agreed upon secret key and returns
it to the sender. Because the nonce was randomly generated by the
sender this defeats playback attacks because the replayer can't know
in advance the nonce the sender will generate. The receiver denies
connections that do not have the correctly encrypted nonce. <P>

<DT> <B>Non-repudiable Information Exchange</B>

<DD> When two entities exchange information it is sometimes valuable
to have a record of the communication that is non-repudiable. Neither
party can then deny that the information exchange occurred. Version 2
of the SSL protocol does not support Non-repudiable information
exchange. <P>

<DT> <B>Public Key Encryption</B>

<DD> Public key encryption is a technique that leverages asymmetric
ciphers. A public key system consists of two keys: a public key and a
private key. Messages encrypted with the public key can only be
decrypted with the associated private key. Conversely, messages
encrypted with the private key can only be decrypted with the public
key. Public key encryption tends to be extremely compute intensive and
so is not suitable as a bulk cipher. <P>

<DT> <B>Privacy</B>

<DD> Privacy is the ability of two entities to communicate without
fear of eavesdropping. Privacy is often implemented by
<I>encrypting</I> the communications stream between the two
entities. <P>

<DT> <B>RC2, RC4</B>

<DD> Proprietary bulk ciphers invented by RSA (There is no good
reference to these as they are unpublished works; however, see
[9]). RC2 is block cipher and RC4 is a stream cipher. <P>

<DT> <B>Server</B>

<DD> The server is the application entity that responds to requests
for connections from clients. The server is passive, waiting for
requests from clients. <P>

<DT> <B>Session cipher</B>

<DD> A session cipher is a "bulk" cipher that is capable of encrypting
or decrypting arbitrarily large amounts of data.  Session ciphers are
used primarily for performance reasons. The session ciphers used by
this protocol are symmetric. Symmetric ciphers have the property of
using a single key for encryption and decryption. <P>

<DT> <B>Session identifier</B>

<DD> A session identifier is a random value generated by a client that
identifies itself to a particular server. The session identifier can
be thought of as a handle that both parties use to access a recorded
secret key (in our case a session key). If both parties remember the
session identifier then the implication is that the secret key is
already known and need not be negotiated. <P>

<DT> <B>Session key</B>

<DD> The key to the session cipher. In SSL there are four keys that
are called session keys: CLIENT-READ-KEY, CLIENT-WRITE-KEY,
SERVER-READ-KEY, and SERVER-WRITE-KEY. <P>

<DT> <B>SERVER-READ-KEY</B>

<DD> The session key that the server uses to initialize the server read
cipher. This key has the same value as the CLIENT-WRITE-KEY. <P>

<DT> <B>SERVER-WRITE-KEY</B>

<DD> The session key that the server uses to initialize the server
write cipher. This key has the same value as the CLIENT-READ-KEY. <P>

<DT> <B>Symmetric Cipher</B>

<DD> A symmetric cipher has the property that the same key can be used
for decryption and encryption. An asymmetric cipher does not have this
behavior. Some examples of symmetric ciphers: IDEA, RC2,
RC4. <P>

</DL>

</DL>
<H3>References</H3>
<DL><DD>

[1] CCITT. Recommendation X.208: "Specification of Abstract Syntax
Notation One (ASN.1). 1988. <P>

[2] CCITT. Recommendation X.209: "Specification of Basic Encoding
Rules for Abstract Syntax Notation One (ASN.1). 1988. <P>

[3] CCITT. Recommendation X.509: "The Directory - Authentication
Framework". 1988. <P>

[4] CCITT. Recommendation X.520: "The Directory - Selected Attribute
Types". 1988.<P>

[5] RSA Laboratories. PKCS #1: RSA Encryption Standard, Version 1.5,
November 1993. <P>

[6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard,
Version 1.5, November 1993. <P>

[7] R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. April 1992. <P>

[8] R. Rivest. RFC 1319: The MD2 Message Digest Algorithm. April 1992. <P>

[9] B. Schneier. Applied Cryptography: Protocols, Algorithms, and
Source Code in C, Published by John Wiley &amp; Sons, Inc. 1994. <P>

[10] M. Abadi and R. Needham. Prudent engineering practice for
cryptographic protocols. 1994. <P>

</DL>

<H3>Patent Statement</H3>

<DL><DD>

This version of the SSL protocol relies on the use of patented public
key encryption technology for authentication and encryption. The
Internet Standards Process as defined in RFC 1310 requires a written
statement from the Patent holder that a license will be made available
to applicants under reasonable terms and conditions prior to approving
a specification as a Proposed, Draft or Internet Standard. <P>

The Massachusetts Institute of Technology and the Board of Trustees of
the Leland Stanford Junior University have granted Public Key Partners
(PKP) exclusive sub-licensing rights to the following patents issued
in the United States, and all of their corresponding foreign patents: <P>

<DL><DD><PRE>
Cryptographic Apparatus and Method
("Diffie-Hellman")............................... No. 4,200,770 <P>

Public Key Cryptographic Apparatus
and Method ("Hellman-Merkle").................... No. 4,218,582 <P>

Cryptographic Communications System and
Method ("RSA")................................... No. 4,405,829 <P>

Exponential Cryptographic Apparatus
and Method ("Hellman-Pohlig").................... No. 4,424,414 <P>

</PRE></DL>

These patents are stated by PKP to cover all known methods of
practicing the art of Public Key encryption, including the variations
collectively known as El Gamal. <P>

Public Key Partners has provided written assurance to the Internet
Society that parties will be able to obtain, under reasonable,
nondiscriminatory terms, the right to use the technology covered by
these patents.  This assurance is documented in RFC 1170 titled
"Public Key Standards and Licenses".  A copy of the written assurance
dated April 20, 1990, may be obtained from the Internet Assigned
Number Authority (IANA). <P>

The Internet Society, Internet Architecture Board, Internet
Engineering Steering Group and the Corporation for National Research
Initiatives take no position on the validity or scope of the patents
and patent applications, nor on the appropriateness of the terms of
the assurance.  The Internet Society and other groups mentioned above
have not made any determination as to any other intellectual property
rights which may apply to the practice of this standard. Any further
consideration of these matters is the user's own responsibility. <P>

</DL>

<H3>Security Considerations</H3>

<DL><DD>This entire document is about security. <P></DL>

<H3>Author's Address</H3>

<DL><DD>

<address>
Kipp E.B. Hickman<br>
Netscape Communications Corp.<br>
501 East Middlefield Rd.<br>
Mountain View, CA 94043<br>
kipp@netscape.com<br>
</address>

</DL>
</BODY>
</HTML>
